Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix image_loader for animated image types #5688

Merged
merged 2 commits into from
Feb 18, 2025
Merged

Conversation

BSteffaniak
Copy link
Contributor

Hi, after upgrading to 0.31.0 all of my beautiful static webp images started failing to load. I use the image_loader to load those via the image crate.

I noticed that with 0.31.0 there are additions to how animated image types are handled with frames and such. And with those changes the frame index is attached to the uri at the end. This was problematic for the image_loader, because it wasn't updated to handle that frame tag at the end of the uri, so when looking up the bytes, it would fail to match the uri in the bytes cache (the bytes were being saved without the frame index, but attempting to be fetched with the frame index).

This fixes the image_loader for me with webp & gif. They don't load the animations, but I think that is because I don't have the custom image_loader set up so I'm not worried about that for myself. I'm not sure if that part is problematic in general, or if its just the way I have my features set up.

You can recreate the issue on master by swapping out the dependency features in the images example like this:

# egui_extras = { workspace = true, features = ["default", "all_loaders"] }
# env_logger = { version = "0.10", default-features = false, features = [
#   "auto-color",
#   "humantime",
# ] }
# image = { workspace = true, features = ["jpeg", "png"] }
egui_extras = { workspace = true, features = ["image", "svg"] }
env_logger = { version = "0.10", default-features = false, features = [
  "auto-color",
  "humantime",
] }
image = { workspace = true, features = ["jpeg", "png", "webp", "gif"] }
  • I have followed the instructions in the PR template

@BSteffaniak
Copy link
Contributor Author

Side note: I think an even better way to handle this would be to not treat static webp/gif images as "animated". The webp spec has an "ANIM" chunk at a specific position in the headers if it is animated, which you could use to determine in addition to searching for the RIFF WEBP header.

I'd be happy to help out with that if you'd like. Otherwise I thought I'd just bring it to your attention in case you haven't thought about that.

@BSteffaniak
Copy link
Contributor Author

@emilk Do you have any concerns with this approach? Without this, my images don't work with the custom image_loader.

@@ -57,6 +58,7 @@ impl ImageLoader for ImageCrateLoader {
// 1. URI extension (only done for files)
// 2. Mime from `BytesPoll::Ready`
// 3. image::guess_format (used internally by image::load_from_memory)
let uri = decode_animated_image_uri(uri).map_or(uri, |(uri, _frame_index)| uri);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like it because I feel like the image loader shouldn't need to know about animated images. The culprit is here, but fixing it there would be a much bigger change so I think this fix is fine fow now.

In theory this should break urls like http://example.com/image.png#123, where the loader now would try to load http://example.com/image.png, but I these urls are very rare so this should be fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, that's why I pointed out that we shouldn't even be treating the static webp images as animated (in is_animated_image_uri). Would you like me to take a look at fixing that?

Copy link
Contributor Author

@BSteffaniak BSteffaniak Feb 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, sorry, I didn't mean that I think this fix should be in is_animated_image_uri. I think it would be around are_animated_image_bytes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For fixing specifically webp, I would image something like this:

has_gif_magic_header(bytes) || (has_webp_header(bytes) && is_animated_webp_header(bytes))

I haven't looked into the gif spec to see if there is a similar header that we could look at for that.

Copy link

Preview available at https://egui-pr-preview.github.io/pr/5688-master
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

@BSteffaniak
Copy link
Contributor Author

@lucasmerlin It looks like this PR is missing a label of some sort. I don't think I can add that, can I?

@lucasmerlin lucasmerlin added egui_extras bug Something is broken labels Feb 18, 2025
@lucasmerlin lucasmerlin added this to the Next Patch Release milestone Feb 18, 2025
@lucasmerlin
Copy link
Collaborator

I don't think I can add that, can I?

No, unfortunately not, only maintainers can. We need the labels for proper changelog generation, thats why we have a pipeline for that

@lucasmerlin lucasmerlin merged commit 770c976 into emilk:master Feb 18, 2025
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is broken egui_extras
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants